Traditional applications have been built within isolated platforms, each performing a fixed set of application functions. For example, applications were defined and built as vendor specific applications, providing a well defined set of functions, with no opportunity to enhance the applications to provide functions beyond what was originally provided by the original design teams. Although such applications serve their original purpose, technological or market developments suggesting new functions to be implemented cannot be accommodated without appreciable modification to the applications (e.g., developing a new version of the full application). Moreover, such applications are limited in their ability to interact with other applications, perhaps providing complementary or related functions. Modifications to traditional applications can require substantial time (e.g., a year or more) to implement, test, and deploy.
Telecommunication service providers have begun to recognize that differentiated services are driving markets more so than the traditional price competition models. For example, telecommunication subscribers are often looking to groups of services that are available when selecting a service provider rather than solely price per minute. Accordingly, rather than specifying or building applications that perform a fixed set of application functions, service providers are evolving their application environments to support the delivery of groups of services, preferably closely bundled (i.e., providing seamless interaction between various functions), to enable them to be more competitive in the rapidly changing service focused market. In addition, applications for telephony services are likely to be increasingly made up of non-telephony media and features. The web services infrastructure is being embraced as a unifying application infrastructure to bring together service components (telephony and non-telephony) into a cohesive logical application creation and deployment environment.
Attempts have been made in the past to provide an open application environment facilitating application function integration for providing desired groups of services. For example, two recently introduced technologies, JAIN SLEE and PARLAY, have addressed issues with respect to the development of open environment applications.
JAIN SLEE is a service logic execution environment for the JAVA platform. JAIN SLEE provides an environment for a developer to create objects, link them together and build logical applications off of multiple individual building blocks. Accordingly, a developer may create self-contained objects that are deployed object by object in a container and those objects dynamically find the other objects that they need to interact with to provide their end application function. However, in JAIN SLEE all the objects are equal, so although the objects define service building blocks and may be mixed and matched as desired by a developer, it is up to the developer to explicitly structure the code for such uses. Moreover, JAIN SLEE is not particularly well focused toward providing telephony services that connect into a web services infrastructure. In addition to the development environment deficiencies, the JAIN SLEE deployment environment is bogged down in hierarchy, having many layers resulting in an overly abstracted deployment layer between the development container and the service network, and is not well suited to robust telephony applications. The JAIN SLEE standards, in addition to the foregoing deficiencies, do not fully support a web services infrastructure.
PARLAY provides a development environment similar to that of JAIN SLEE. That is, PARLAY provides a dynamic object based development environment and provides a framework for object life management. However, PARLAY, in addition to object life management, facilitates defining how the objects are to be made use of within the development environment and specifies its participation into a web services infrastructure. Accordingly, PARLAY has a well defined hierarchy of objects within its development environment that clarifies how developers need to build their applications to make them work in the environment. In addition, PARLAY is somewhat telephony focused, providing a developer with mechanism to overlay external policies on top of the applications in order to provide central way of dictating how resources in a service network are going to be used in relation to the applications put on the platform. However, PARLAY is only a development container, and therefore does not define any deployment platform or environment underneath it. Accordingly, the actual products that host/support PARLAY development environments are all unique, but with a well defined application environment on top of them.
The session initiation protocol (SIP) servlet container has been adopted by the IMS standards as the preferred SIP application server (A/S). However, the SIP servlet containers only address the deployment side of the problem. Accordingly, a SIP servlet container may be used to provide an open container that allows a developer to do object oriented design for telephony applications, but does not provide any special tools or architecture or infrastructure to better enable the developers to design such applications. Further, the SIP servlet container provides no facility to connect applications or services deployed on a SIP servlet container to the overall web services application infrastructure preferred by service providers.
It can be appreciated that an application environment may be thought of as including a development environment and a deployment environment. Although, both JAIN SLEE and PARLAY appear to provide useful application development environments as set forth above, both JAIN SLEE and PARLAY present difficulties when attempting to deploy telephony applications. In contrast, to JAIN SLEE and PARLAY, SIP servlet (JSR116) containers are well suited to deploying robust telephony applications. However, the standards governing SIP servlet containers have lacked a suitable development environment for creating and deploying distributed, logical applications.
From the above, it can be seen that developers and service providers are presented with problems in developing and deploying open applications for use in telephony. Such developers and service providers can select a deployment platform that meets their carrier requirements, but which does not provide a robust development environment, or they can select a development platform having better development tools for facilitating rapid service creation, but which suffers disadvantages with respect to the deployment environment.